16장 화면 시안 빠르게 만들기 (입문판)

출처: 클로드 코드 완벽 가이드, 코드팩토리 최지호

이 장에서 딱 3가지만 1. 어떤 프레임워크로 시작할지 고르는 법 (내가 아는 것 + 대중적인 것) 2. PRD를 바탕으로 화면 시안 하나를 빠르게 만드는 법 (플래닝 모드) 3. 한 번에 여러 시안을 동시에 만들어 나란히 비교하는 법 (worktree + subagent)

이 장의 학습 목표 이 장을 다 읽으면 당신은 이렇게 할 수 있다. - 화면 시안을 만들 프레임워크를 고르는 두 가지 기준을 설명한다. - PRD를 플래닝 모드에 붙여넣어 시안 하나를 따라 만든다. - 단일 시안 방식과 동시 다중 시안 방식을 구분한다.

참고로 PRD가 뭔지, 어떻게 쓰는지는 앞 장(15장)에서 다뤘다. 이 장은 그 PRD를 "화면"으로 바꾸는 단계다.

0. 들어가기 전에 — 이 장에서 나오는 말

어려운 말은 0장 용어집에 정리되어 있다고 보면 된다. 다만 이 장에서 처음 나오는 말은 처음 등장할 때 한 줄로 뜻을 적어둔다.

미리 가볍게 짚고 갈 말 몇 개.

화면 시안 완성된 진짜 화면이 아니라, "이런 느낌으로 갈까?" 하고 먼저 보여주는 가짜 화면. 옷 사기 전에 입어보는 마네킹 코디 같은 것.

프로토타입 기능은 아직 없고 겉모습과 흐름만 있는 시제품. 모델하우스가 진짜 집은 아니지만 방 배치는 보여주는 것과 같다.

1. 어떤 도구로 시작할까 — 프레임워크 고르기

1-1. 이런 적 있죠?

새 프로젝트를 시작하면서 이렇게 생각한 적 있을 거다. "요즘 핫하다는 신기술로 만들어볼까? AI가 알아서 다 해주겠지."

그런데 막상 만들다가 버그가 하나 나면 어떻게 될까. 처음 보는 도구라 어디가 잘못됐는지 나도 모르고, AI도 자꾸 헤맨다. 결국 손도 못 대고 멈춘다.

이게 바로 "프레임워크를 잘못 고른" 상황이다.

프레임워크 웹사이트나 앱을 만들 때 쓰는 "기본 틀 + 도구 세트". 요리로 치면 칼, 도마, 냄비가 한 세트로 묶인 주방 키트다.

1-2. 비유 먼저 — 요리 도구 세트 고르기

프레임워크 고르기는 요리 도구 세트 고르기와 같다.

아무리 훌륭한 AI 셰프(클로드 코드)라도, 낯선 도구를 주면 실수가 많아진다. 반대로 전 세계가 다 쓰는 흔한 도구를 주면 척척 잘 만든다.

1-3. 고르는 기준은 딱 두 가지

기준 1 — 내가 어느 정도 아는 프레임워크인가?

AI가 코드를 대신 써준다고 해서 버그가 0이 되는 건 아니다. 바이브 코딩(AI에게 시켜서 코딩하는 방식)이 아무리 좋아져도, 한 번에 버그 없이 완성되는 일은 없다.

버그가 나면 결국 내가 최소한 어디가 문제인지는 봐야 한다. 그러려면 기본 구조 정도는 아는 도구로 시작하는 게 좋다.

잘못된 생각 vs 올바른 생각 - 잘못된 생각: "처음 보는 프레임워크지만 AI가 다 해주니까 괜찮아." → 버그가 나면 나도 AI도 멈춘다. - 올바른 생각: "기본은 아는 도구라, 최소한 디버깅은 내가 거들 수 있어." → 막혀도 같이 풀어나갈 수 있다.

디버깅 프로그램에서 잘못된 곳(버그)을 찾아 고치는 일. 옷에서 튿어진 실밥을 찾아 꿰매는 것과 비슷하다.

기준 2 — 대중적인 프레임워크인가?

AI는 많이 배운 것을 잘한다. 세상에 예제가 많은 기술일수록 AI가 더 잘 만든다. 특히 화면(UI) 만들기에서 이 차이가 가장 크게 난다.

UI User Interface, 사용자가 보고 누르는 화면. 버튼, 메뉴, 글자처럼 눈에 보이는 부분 전부.

이럴 때 이렇게 (미니 시나리오) - 상황: 친구가 "남들 안 쓰는 희귀 프레임워크로 멋지게 가자"고 한다. - 이렇게: "AI가 잘 만드는 게 중요하니까 사람들이 많이 쓰는 걸로 가자"고 제안한다. - 이유: 예제가 많아야 AI 결과물 품질이 올라간다.

1-4. 이 책이 추천하는 조합

이 책은 화면 시안을 만들 때 이 세 가지 조합을 추천한다.

Next.js React를 기반으로 한 인기 웹 프레임워크. 이 책에서는 App Router라는 방식으로 쓴다(파일을 폴더에 넣으면 자동으로 주소가 생기는 방식).

Shadcn/ui 복사-붙여넣기로 가져다 쓰는 화면 부품 모음. 필요한 버튼이나 카드를 그때그때 내 프로젝트에 복사해 쓴다.

Tailwind CSS 화면에 색·크기·여백을 빠르게 입히는 스타일 도구. 긴 CSS 대신 짧은 이름표(class)를 붙여 꾸민다.

세 가지를 같이 쓰면 AI가 가장 익숙하게, 가장 예쁘게 화면을 만든다.

핵심 정리 - 프레임워크는 화면 품질에 직접 영향을 준다. - 고를 때 기준은 둘. 내가 아는 것 + 대중적인 것. - 이 책 추천 조합은 Next.js + Shadcn/ui + Tailwind CSS.

한 걸음 더 ▸ App Router와 Server Component Next.js에는 App Router라는 최신 방식이 있고, 그 안에 Server Component가 있다. Server Component는 서버에서 미리 그려서 보내주는 화면 부품이라, 검색 노출(SEO)과 속도에 유리하다. 지금은 "AI에게 부탁할 때 App Router 기반으로, Server Component 우선으로 만들어줘"라고 말하면 된다 정도만 알면 충분하다.

1-5. 초기 설정에 같이 깔리는 두 도구 — ESLint와 Prettier

프로젝트를 처음 만들면, 위 세 가지(Next.js·Shadcn/ui·Tailwind) 말고도 이름표 두 개가 슬쩍 같이 따라온다. 바로 ESLint와 Prettier다.

처음 보면 "이건 또 뭐지?" 싶지만, 둘 다 글쓰기 도우미라고 생각하면 쉽다. 하나는 틀린 곳을 잡아주고, 하나는 모양을 가지런히 정리해준다.

ESLint 코드의 문법 오류와 스타일 실수를 검사해주는 도구. 문서 작성기의 맞춤법 검사기처럼, 틀린 곳에 빨간 줄을 그어 알려준다.

Prettier 코드 모양(들여쓰기·줄바꿈·간격)을 자동으로 가지런히 정리해주는 도구. 글을 쓰고 나서 "줄 맞춤" 버튼 한 번 누르면 반듯해지는 것과 같다.

잘못된 생각 vs 올바른 생각 - 잘못된 생각: "이상한 게 같이 깔렸네, 지워야 하나?" → 멀쩡한 도우미를 지워서 코드가 더 지저분해진다. - 올바른 생각: "맞춤법·줄맞춤 도우미구나, 그냥 두면 알아서 도와준다." → 손 안 대도 코드가 깔끔하게 유지된다.

이럴 때 이렇게 (미니 시나리오) - 상황: 초기 설정 목록에 ESLint, Prettier가 보여서 "이게 뭐지?" 싶다. - 이렇게: 둘 다 코드를 깔끔하게 지켜주는 도우미라고 알아두고 그대로 둔다. - 이유: AI가 만든 코드의 실수를 잡고 모양을 정리해줘서 결과물이 더 단정해진다.

핵심 정리 - 초기 설정에는 화면 도구 셋 말고 ESLint·Prettier도 같이 깔린다. - ESLint는 틀린 곳을 잡고(맞춤법 검사기), Prettier는 모양을 정리한다(줄맞춤). - 굳이 지우지 말고 그대로 두면 코드가 알아서 깔끔하게 유지된다.

2. 시안 하나 빠르게 만들기 — 플래닝 모드

2-1. 이런 적 있죠?

AI에게 "사이트 하나 만들어줘" 했더니, 묻지도 따지지도 않고 갑자기 코드를 와르르 쏟아낸 적 있을 거다. 나중에 보니 내가 원한 것과 한참 다르고, 되돌리기도 힘들다.

그래서 코드를 바로 짜기 전에 "계획부터 보여줘"라고 시키는 단계가 필요하다. 그게 바로 플래닝 모드다.

플래닝 모드 클로드 코드가 코드를 바로 쓰지 않고, "이렇게 할게요" 하고 계획(순서, 할 일 목록)을 먼저 보여주는 모드. 공사 들어가기 전에 시공 계획서를 먼저 받아보는 것과 같다.

2-2. 비유 먼저 — 건축 모형 만들기

시안 만들기는 건축 모형 만들기와 같다.

진짜 집을 짓기 전에 미니어처 모형을 먼저 만든다. 모형은 수도·전기는 안 나오지만(기능 없음), 방 배치와 동선은 보인다(화면 구성). 마음에 안 들면 쉽게 바꾼다(빠른 수정).

PRD Product Requirements Document, 만들 서비스의 목적·기능·화면을 정리한 문서. 15장에서 쓰는 법을 배웠다. 여기서는 "이 문서를 화면으로 바꾼다"가 핵심이다.

2-3. 따라 하기 — 4단계

안전한 기본 길부터 보자. 순서는 네 단계다.

1단계 — 클로드 코드 실행 VS Code(코드 편집기)에서 터미널을 열고 클로드 코드를 실행한다.

2단계 — 플래닝 모드로 바꾸고 PRD 붙여넣기 키보드에서 Shift + Tab을 눌러 플래닝 모드로 바꾼다. 그다음 이렇게 부탁하고, 아래에 PRD 내용을 붙여넣는다.

아래 PRD를 기반으로 새로운 Next.js 프로젝트를 구성해줘.
Shadcn, Tailwind를 사용해주고, 기능은 구현하지 말고 UI만 제작해줘.
Next.js는 꼭 App Router 기반으로, Server Component를 우선시해서 구현해줘.
(여기 아래에 PRD 전체를 붙여넣기)

여기서 중요한 한마디는 "기능은 구현하지 말고 UI만 제작해줘"다. 이 말을 빼면 AI가 실제 동작까지 만들려다 일이 커진다.

3단계 — 작업량 확인 (가장 중요) AI가 코드를 짜기 전에 계획을 보여준다. 보통 이런 식이다. - 1단계: 프로젝트 초기 설정 (Next.js, Tailwind, Shadcn/ui 등) - 2단계: 폴더·파일 구조 잡기 - 그리고 할 일 목록(Todo)을 자동으로 만들어준다.

이때 "혹시 UI 말고 다른 작업이 끼어 있지 않나?"를 꼭 살핀다. 화면만 만들어 달랬는데 로그인 기능, 데이터베이스 같은 게 계획에 들어 있으면 빼달라고 한다.

4단계 — Yes 선택 계획이 괜찮으면 Yes를 골라 실제 만들기를 시작한다. 잠시 뒤 PRD와 꽤 비슷한 화면 시안이 만들어진다.

[Shift+Tab] 플래닝 모드 →
프롬프트 + PRD 붙여넣기 →
계획 확인 (UI만 있나?) →
[Yes] → 시안 완성

2-4. 왜 작업량 확인이 그렇게 중요할까

AI는 의욕이 넘쳐서 시키지 않은 일까지 앞서 해버리는 경향이 있다. 특히 똑똑한 모델일수록 "이왕 하는 김에 전체 다 만들자"며 범위를 넘기 쉽다.

원서/노트 기준 예시로, Opus 모델은 한 번에 전부 구현하려는 성향이 강하다고 한다. (모델 종류·성향은 시간이 지나면 바뀔 수 있으니, 최신 정보는 공식 문서에서 확인하면 된다.)

그래서 계획 단계에서 "화면 외 작업이 끼지 않았는지" 확인하는 습관이 안전하다.

잘못된 예 vs 올바른 예 - 잘못된 예: 계획을 안 보고 바로 Yes → 원하지 않은 기능까지 잔뜩 생김 → 다시 지움. - 올바른 예: 계획에서 범위 밖 항목을 빼달라고 한 뒤 Yes → 딱 화면만 깔끔히 생김.

핵심 정리 - 플래닝 모드는 Shift + Tab으로 켠다. - 프롬프트에 "기능 말고 UI만"을 꼭 넣는다. - Yes 누르기 전에 계획에 군더더기 작업이 없는지 확인한다. - 같은 부탁이라도 결과는 매번 조금씩 다를 수 있다(AI의 특성).

2-5. 만들다 오류가 나면 — 오류는 통째로 복사

처음 세팅 중에 빨간 오류 메시지가 뜰 수 있다. 당황하지 말자.

이런 적 있죠? 오류가 나면 구글에 검색하려고 메시지를 줄여서 적는다. 그런데 핵심을 잘못 줄여서 엉뚱한 답만 나온 경험, 있을 거다.

클로드 코드에는 오류를 "통째로" 줄 수 있다. 이게 훨씬 낫다.

왜 통째로가 나을까 클로드 코드는 지금 내 프로젝트 전체(코드·설정·연결된 부품)를 이미 보고 있다. 그래서 오류 전체를 그대로 주면 맥락까지 합쳐 정확한 답을 준다.

잘못된 예 vs 올바른 예 - 잘못된 예: "bg-background 에러가 나요" (요약만) - 올바른 예: 아래처럼 통째로 붙여넣기

아래 에러가 발생하는데 왜 그런지 알려줘
--------------------------------
Error: Cannot apply unknown utility class `bg-background`
  [at onInvalidCandidate (.../tailwindcss/...)]
  [at ge (.../tailwindcss/...)]
  ...스택 트레이스 전부 그대로...

그래도 안 풀릴 때 (한 걸음 더) - 확장된 사고를 켠다. AI가 더 깊이 천천히 생각해서 푼다. 확장된 사고(Extended Thinking): 클로드가 답하기 전에 더 오래 곰곰이 따져보는 기능. 어려운 문제일수록 도움이 된다. - 더 강한 모델(원서/노트 기준 예시로 Opus)로 바꿔 다시 물어본다. (모델명은 바뀔 수 있으니 최신 값은 공식 문서에서 확인.)

이럴 때 이렇게 (미니 시나리오) - 상황: 세팅 직후 스타일 관련 빨간 오류가 뜬다. - 이렇게: 오류 전체를 그대로 복사해 "왜 이 에러가 나는지 알려줘"와 함께 붙여넣는다. - 그래도 막히면: 확장된 사고를 켜거나 더 강한 모델로 다시 묻는다.

핵심 정리 - 오류는 요약하지 말고 전체를 복사해 전달한다. - 클로드 코드는 프로젝트 맥락을 알고 있어 구글 검색보다 정확할 때가 많다. - 안 풀리면 확장된 사고 → 더 강한 모델 순으로 올린다.

3. 한 번에 여러 시안 만들기 — worktree와 subagent

3-1. 이런 적 있죠?

시안 하나를 만들었는데 마음에 안 든다. 그래서 "다시" 시키고, 또 안 들어서 "다시" 시키고… 이걸 반복하다 보면 앞에 본 시안이 어땠는지 기억도 안 난다.

차라리 처음부터 여러 개를 동시에 만들어 나란히 놓고 고르면 어떨까? 그게 이 절의 주제다.

3-2. 비유 먼저 — 인테리어 업체 4곳에 동시 의뢰

여러 시안 동시 제작은 인테리어 업체 4곳에 한꺼번에 맡기는 것과 같다.

한 곳에만 맡기면: 시안 받고 → 마음에 안 들면 다시 → 반복. 느리고 비교가 어렵다. 네 곳에 동시에 맡기면: 4가지 시안을 한 번에 받아 나란히 비교. 빠르고 다양하다.

Git worktree 하나의 Git 저장소에서 작업 폴더를 여러 개 동시에 두는 기능. 한 집 안에 따로 쓰는 작업실을 여러 개 만드는 셈이라, 서로 안 섞인다.

subagent 클로드 코드가 만드는 "보조 일꾼" 에이전트. 큰일을 나눠 여러 일꾼에게 동시에 시키면 빨리 끝난다.

커스텀 커맨드 내가 직접 만들어 두는 단축 명령어. .claude/commands/ 폴더에 마크다운 파일로 저장하면 /이름으로 부른다. 자주 쓰는 긴 지시를 단축키 하나로 저장해두는 것과 같다.

3-3. 따라 하기 — 4단계

1단계 — 먼저 커밋하기 (필수) worktree는 커밋된 상태에서만 만들 수 있다. 그러니 먼저 현재 상태를 저장한다.

git add .
git commit -m "초기 커밋"

커밋 지금까지 한 작업을 저장하는 Git의 "저장 도장". 게임에서 세이브 포인트를 찍는 것과 같다.

2단계 — 지시서(커스텀 커맨드) 파일 만들기 .claude/commands/create-designs.md 파일을 만들고 아래 같은 내용을 적는다.

# Persona
너는 지금부터 UI 전문가야. 현재 프로젝트의 시안을 4개 더 만들려고 해.

# 작업
아규먼트로 입력한 4가지 테마로 4개의 UI 시안을 제작해줘.
4개의 시안은 모두 독립적인 subagent를 생성해서 동시에 parallel하게 작업해줘.

## 각 subagent별 작업 방법
- worktree를 생성해줘  git worktree add ./worktree/agent-$AGENT_NUMBER
- 할당된 디자인 스타일로 UI를 변경해줘
- 시안을 볼 수 있도록 서버를 시작해줘
  PORT=400$AGENT_NUMBER pnpm -C ./worktree/agent-$AGENT_NUMBER dev
- 만약 에러가 있다면 시작될 때까지 수정해줘

아규먼트 명령을 부를 때 같이 넘기는 추가 입력값. "커피 주문"에 "아이스로, 샷 추가" 같은 옵션을 붙이는 것과 같다. 여기서는 "어떤 테마 4개로 만들지"를 넘긴다.

3단계 — 커맨드 실행 저장한 명령을 부르면서 테마 4개를 넘긴다.

/create-designs 미니멀 테마, 네온 사이버 테마, 네이처 테마, 럭셔리 테마

4단계 — 결과 비교 4개의 일꾼이 각각 다른 작업실(worktree)에서 만들고, 서로 다른 포트(4001, 4002, 4003, 4004)로 화면을 띄운다. 브라우저에서 네 주소를 나란히 열어 비교하고, 마음에 드는 걸 메인 프로젝트에 반영한다.

포트 한 컴퓨터에서 여러 서버를 구분하는 번호. 같은 건물의 호수(101호, 102호)처럼, 번호로 어느 화면인지 구분한다.

agent-1 → 포트 4001 → 미니멀 테마
agent-2 → 포트 4002 → 네온 사이버 테마
agent-3 → 포트 4003 → 네이처 테마
agent-4 → 포트 4004 → 럭셔리 테마
→ 4개를 한눈에 비교!

3-4. 지시문에 영어를 살짝 섞는 이유

위 지시서를 보면 "동시에 parallel하게"처럼 영어가 섞여 있다. 일부러 그렇게 쓴 거다.

이유: 클로드(AI)는 영어 자료를 아주 많이 보고 배웠다. 그래서 기술 용어는 영어로 짚어주면 더 정확히 알아듣는다.

잘못된 예 vs 올바른 예 - 약간 모호: "병렬로 작업해줘" (한국어만) - 더 정확: "독립적인 subagent를 생성해서 동시에 parallel하게 작업해줘"

주의: 글 전체를 영어로 쓰라는 말이 아니다. 평소엔 편한 한국어로 쓰되, subagent·parallel 같은 핵심 기술 용어만 영어로 콕 짚어주면 된다.

핵심 정리 - 여러 시안을 만들려면 먼저 git commit으로 상태를 저장한다. - 커스텀 커맨드는 .claude/commands/에 마크다운으로 저장한다. - worktree로 작업실을, subagent로 일꾼을 여러 개 두면 동시에 만든다. - 각 시안은 다른 포트(4001~4004)로 띄워 나란히 비교한다. - 핵심 기술 용어는 영어를 살짝 섞으면 AI가 더 잘 알아듣는다.

4. 한눈에 비교표

화면 시안 vs 진짜 앱 개발

프레임워크 고르기 (AI로 화면 만들 때)

이 표는 원서/노트 기준 예시다. 도구 인기와 품질은 시간이 지나면 바뀔 수 있으니, 최신 흐름은 공식 문서나 커뮤니티에서 확인하면 된다.

시안 하나 vs 여러 개 동시

5. 정리하며

이 장에서 한 일을 한 줄씩 다시 보자.

도구는 내가 아는 것 + 대중적인 것으로 고른다(Next.js + Shadcn + Tailwind). PRD를 플래닝 모드에 붙여넣고, "UI만"을 강조한 뒤, 계획을 확인하고 Yes를 누른다. 오류는 통째로 복사해 전달하고, 안 풀리면 확장된 사고나 더 강한 모델로 올린다. 여러 시안은 git commit → 커스텀 커맨드 → worktree + subagent로 동시에 만들어 비교한다.

연습 삼아 해보기 1. 프레임워크를 고르는 두 기준은 무엇인가? 한 줄씩 적어보자. 2. 플래닝 모드는 어떤 키로 켜는가? 그리고 Yes 전에 꼭 확인할 것은? 3. 오류가 났을 때 클로드 코드에 어떻게 전달하는 게 좋은가? 4. 여러 시안을 동시에 만들려면 먼저 무엇을 해야 하는가?

다음 장 예고: 다음 장에서는 이렇게 만든 시안을 더 다듬고 발전시키는 이야기를 이어간다. 지금 당장 몰라도 된다 — 이 장의 시안 만들기만 손에 익으면 충분하다.

참고로 도구의 모델명·요금·옵션 같은 정보는 빠르게 바뀐다. 이 책에 적힌 구체적인 값은 원서 작성 시점 기준 예시이니, 실제로 쓸 때는 공식 문서에서 최신 값을 확인하면 된다.